【レポート】AWS Schema Conversion Tool を使用したデータベースエンジン移行のポイント #dbts2020

こんにちは、崔です。

現在、2020年10月27日〜12月10日の期間で開催されている db tech showcase ONLINE 2020 のセッション「AWS Schema Conversion Tool を使用したデータベースエンジン移行のポイント」を、本日視聴しましたので、レポートをお届けします。

セッション情報

概要

AWSへの移行を検討する際に、データベースエンジンの移行も同時に検討するケースが多くみられます。
AWS Schema Conversion ToolはスキーマやSQLをターゲットデータベース互換のフォーマットに変換することが可能です。
本セッションでは、AWS Schema Conversion Toolを使用してスキーマを移行する際のポイント、移行時の課題とその解決策についてご紹介致します。

スピーカー

アマゾン ウェブ サービス ジャパン 株式会社
技術統括本部 レディネスソリューション本部 ソリューションアーキテクト
内山 義夫 様

アジェンダ

• はじめに
• AWS Schema Conversion Toolとは
• 机上検討におけるSCTの使用
• PoCでのSCTの使用
• まとめ

はじめに

データベースの移行を検討しているお客様の声

• クラウドにシステム全体を移行するのであれば、RDBMSもクラウドネイティブにしたい
• DBもオートスケールしたいが、CPUライセンスだとできない
• IT予算の多くをOracleのライセンスが締めている

など

移行にあたっての不安や悩み

• データベースの移行に関して何を検討するのか
• 実際にどのような検証を行えばよいか
• 移行のために何を行う必要があるか

データベース移行のプロセス

• 検討
  • 机上検討やPoC
  • DBマイグレーションが妥当なのか検討
• 設計
• 変換
• 移行
• 運用
• 最適化

検討フェーズにおける検討事項

• 机上検討
  • 移行実現可能性の評価
    • 移行できないオブジェクトや機能の調査 → SCTの評価レポートを利用する
    • データベースエンジン間の仕様差異による影響調査
• PoC（機能／性能検証）
  • 重要度の高い処理や移行が懸念される処理をピックアップ
  • ターゲットDBのスキーマ作成、手動変換 → SCTによるスキーマ作成
  • 変換後、移行前後で処理結果や処理時間を比較

AWS Schema Conversion Toolとは

SCT

データベースやデータウェアハウスをAWSに移行可能

SCTの使用用途

• 評価レポートの作成
• スキーマの移行
  • ターゲットのデータベースに適用
• アプリケーションソースコードの移行
  • スキーマだけではなく、ソースコードのSQLも変換可能

SCTの設定手順

• SCTをインストールし、起動
• データベース選択（ソース／ターゲット）
• 接続先のDBを設定

SCTは無料で利用できる

メインビュー：スキーマ／コード変換

左側にソースデータベースのオブジェクト一覧が表示される
右側にターゲットデータベースのオブジェクト一覧が表示される

SCTインストール時のポイント

• 移行元DBに接続できればオンプレミス／EC2どちらでも使用可能
• 接続元データベースの設定変更不要
• ステージング環境や開発環境に接続することで、本番環境への影響を与えずに分析可能

机上検討におけるSCTの利用

評価レポートの作成

• SCTで、対象スキーマを選択
• Create reportを選択

SCTの評価レポート

• ソースおよびターゲットデータベースの組み合わせに合わせた評価レポート
• 概要としてオブジェクトの移行がどの程度の難易度か表示
• 変換工数の事前見積を補助
  • 自動変換可能
  • 簡単なアクションが必要（1時間以内）
  • 複雑なアクションが必要（4時間以内）
  • 大規模なアクションが必要（4時間以上）
• 自動変換が出来ない場合は詳細レベルの原因や推奨アクションが提示される
• 自動変換できないオブジェクトの情報を一覧で確認したい場合、CSVに出力することも可能
  • 手動変換対象を確認できる

Application 評価レポート

• 既存のJavaなどのソースコードを解析し、ソースコード中のSQL文をターゲットデータベースに自動変換可能か評価
• 変換エラーに対して、どういったエラーだったか調査できる
  • コメントや動的SQLなど、自動抽出されないパターン
  • ターゲットデータベースに合わせたSQL文に自動変換できないパターン

データベースエンジン間の仕様差異

• OracleとPostgreSQLの仕様差異を以下に紹介

NULLと空文字

本来、空文字とは長さゼロバイトの文字列を指す。NULLとは異なるはず
Oracleは、空文字をNULLとして扱う
PostgreSQLは、空文字を長さゼロバイトの文字として扱う
そのため、Oracleで利用されている空文字は、NULLへ置き換える必要がある

DDLの暗黙COMMIT

Oracleでは、トランザクション内でDDLを実行した場合、暗黙的にCOMMITされる
PostgreSQLは、DDLもDMLと同じトランザクションの一部であり、暗黙的にはCOMMITされない
例えば、Truncate後にOracleはCOMMITが不要だが、PostgreSQLは必要となる
DDL実行後にCOMMITを追加する必要がある
（後続の処理のエラー処理でROLLBACKされてしまうことがある）

PoCにおけるSCTの利用

ターゲットDBにスキーマ作成

• ターゲットDBに接続
• スキーマを移行
• ターゲットDBに適用

プロシージャの変換例（Oracle → PostgreSQL）

Oracle PL/SQL から PostgreSQL PL/pgSQLへの移行
宣言部、実行部、例外処理部や、カーソル、ループ処理、なども変換される

OracleからPostgreSQL変換時によくある変換エラー

• 自動変換されない記述を多用したスクリプト例
• 変換エラーが出力される
• 手動で変換が必要なものがリスト化される

自動変換されない原因調査方法

• 変換エラーに表示されたオブジェクトを選択すると、対象行がハイライトされる
• 変換エラーメッセージや詳細を参照しながら、変換エラーの原因を調査

変換エラー例

• Issue:5610 This statement references to a synonym の例
  • シノニムが利用されている。PostgreSQLにはシノニムが存在しない

• Issue:5334 Unable to convert statements with dynamic SQL statement
• Issue:5078 Dynamic SQL table dependency
  • 動的SQLを生成している箇所が変換されない
  • 手動で対応

• Issue:5208 Unable to convert unsupported datatypes
  • 自動変換できなかったデータ型が存在する場合出力される
  • 他の型で代替できないか検討が必要

• Issue:5340 Unable to convert functions
  • 変換できない関数を利用している場合
  • dbms_statsによる統計情報取得処理など。analyzeに変更する

• Issue:5598 PostgreSQL doesn't support a ROWID
• Issue:5578 Unable to automatically transform the SELECT statement
• Issue:5550 PostgreSQL doesn't have a data type ROWID
  • ROWIDに関わるエラー
  • 主キーやROWID列を追加するなどで対応

• Issue:5663 PL/SQL pragma is unsupported
  • 自律型トランザクションを指定している場合のエラー
  • dblink_fdwを使用した関数に変換される

• Issue:5561 PostgreSQL doesn't support this pre-defined exception
  • 例外処理のうち自動変換できなかったもの
  • 変換できるかどうかを確認する必要がある

ホワイトペーパー Database Migration Playbook

DBオブジェクトごとにどのように移行すればよいかをまとめたベストプラクティス集
リソース - AWS Database Migration Service | AWS

まとめ

• データベースエンジン移行に向けては、机上検討、PoC が重要
• AWS Schema Conversion Tool はデータベースエンジン移行を支援
  • 評価レポートの作成
  • 移行工数の見積
  • オブジェクトを自動変換
  • 自動変換できない原因を表示
  • アプリケーションのソースコードも評価

感想

データベースエンジンの変更を伴うDB移行は、オブジェクト移行やSQL移行が大変な労力がかかります。
しかしながら、SCTを利用することで、オブジェクトやSQLが複雑でなければ自動変換することができます。
また、自動変換できない箇所も、ホワイトペーパーとしてまとまっていますので、そちらを参照することで対応工数を減らすことができます。
まずは、SCTの評価レポートを出力してみて、移行元のDBがどの程度自動変換できるのか、手動変換の工数はどの程度かかるのか、見積もってみてはいかがでしょうか。